IRIX Base Documentation 2002 November

home *** CD-ROM | disk | FTP | other *** search

/ IRIX Base Documentation 2002 November / SGI IRIX Base Documentation 2002 November.iso / usr / share / catman / p_man / cat4 / dmedia / datframe.z / datframe

Wrap

Text File | 2002-10-03 | 31.3 KB | 727 lines

DDDDAAAATTTTFFFFRRRRAAAAMMMMEEEE((((4444)))) DDDDAAAATTTTFFFFRRRRAAAAMMMMEEEE((((4444)))) NNNNAAAAMMMMEEEE datframe - structure of a frame of audio data on Digital Audio Tape (DAT) SSSSYYYYNNNNOOOOPPPPSSSSIIIISSSS ####iiiinnnncccclllluuuuddddeeee <<<<ddddaaaattttaaaauuuuddddiiiioooo....hhhh>>>> DDDDEEEESSSSCCCCRRRRIIIIPPPPTTTTIIIIOOOONNNN The Digital Audio Tape (DAT) recorder system is very complex. This man page gives the most useful and relevant information for DAT use in professional systems. It is by no means comprehensive. Conflicts and questions must be resolved by reference to the definitive _D_A_T _C_o_n_f_e_r_e_n_c_e specification referenced below. Audio on Digital Audio Tapes (DAT) is blocked into _f_r_a_m_e_s. A DAT recording has 33.33 frames every second. One frame of data contains both audio and non-audio data (known as subcodes). A program reading or writing a DAT in audio mode must _r_e_a_d(_2) or _w_r_i_t_e(_2) a minimum of one DAT frame. The _d_t_f_r_a_m_e structure, describing the content of a frame of DAT data, is defined in <<<<ddddaaaattttaaaauuuuddddiiiioooo....hhhh>>>> as follows: typedef struct dtframe { char audio[DTDA_DATASIZE]; struct dtsubcode sc; } DTFRAME Audio samples in the _a_u_d_i_o array are linearly encoded in a 16-bit 2's complement format. Encoding is carried out either without pre-emphasis or with a first order 50/15 Ms pre-emphasis. Pre-emphasis is not recommended for professional use. Other encodings are supported by the DAT format but are not permitted in professional use. The data stream contains two interleaved channels, usually used as the left and right channels of a stereo signal. The sample representing the left channel is first, followed by the sample representing the right channel. The _D_A_T _C_o_n_f_e_r_e_n_c_e recommends sampling both both left and right channels simultaneously during recording. The IRIS Indigo and Personal IRIS 4D/35 audio ADC hardware samples both channels simultaneously. The least significant byte of each 16-bit value is first. The bytes need to be swapped in order to match the native byte ordering of the IRIS Indigo and Personal IRIS 4D/35 and their audio hardware. So each 4-byte chunk of the data array represents a pair of samples (1 left plus 1 right) as follows. Byte 0 is the least significant byte of the left channel sample; byte 1 is the most significant byte of the left channel sample. Byte 2 is the least significant byte of the simultaneous right channel sample; byte 3 is the most significant byte of the simultaneous right channel sample. PPPPaaaaggggeeee 1111 DDDDAAAATTTTFFFFRRRRAAAAMMMMEEEE((((4444)))) DDDDAAAATTTTFFFFRRRRAAAAMMMMEEEE((((4444)))) DTDA_DATASIZE is 5760 bytes. SSSSuuuubbbbccccooooddddeeeessss The _d_t_s_u_b_c_o_d_e structure contains subcode information that is recorded on several different areas of the tape. ssssttttrrrruuuucccctttt ddddttttssssuuuubbbbccccooooddddeeee is defined in _d_a_t_a_u_d_i_o._h as follows: typedef struct dtsubcode { struct dtsubcodepack packs[7]; struct dtsubid { unchar ctrlid:4, dataid:4; unchar pno1:4, numpacks:4; unchar pno2:4, pno3:4; unchar ipf; } sid; struct dtmainid { unchar fmtid:2; unchar emphasis:2; unchar sampfreq:2; unchar numchans:2; unchar quantization:2; unchar trackpitch:2; unchar copy:2; unchar pack:2; } mid; } DTSUBCODE; In referring to the _D_A_T _C_o_n_f_e_r_e_n_c_e specification, you need to know that the _m_i_d field contains the bits from the ID field of the main data area otherwise known as the MMMMaaaaiiiinnnn IIIIDDDD bits. The _s_i_d field contains the bits from the ID field of the sub data area, otherwise known as SSSSuuuubbbb IIIIDDDD bits. The _p_a_c_k_s field contains all seven data packs from the sub-data area of the tape. MMMMaaaaiiiinnnn IIIIDDDD BBBBiiiittttssss The bits of the mmmmiiiidddd field have the following meanings and values: value meaning ffffmmmmttttiiiidddd:::: 0 for audio use 1 reserved 2 reserved 3 reserved value meaning eeeemmmmpppphhhhaaaassssiiiissss:::: 0 off 1 50/15 Msec 2 reserved 3 reserved PPPPaaaaggggeeee 2222 DDDDAAAATTTTFFFFRRRRAAAAMMMMEEEE((((4444)))) DDDDAAAATTTTFFFFRRRRAAAAMMMMEEEE((((4444)))) value meaning ssssaaaammmmppppffffrrrreeeeqqqq:::: 0 48kHz 1 44.1kHz 2 32kHz 3 reserved value meaning nnnnuuuummmmcccchhhhaaaannnnssss:::: 0 2 channels 1 4 channels 2 reserved 3 reserved value meaning qqqquuuuaaaannnnttttiiiizzzzaaaattttiiiioooonnnn:::: 0 16-bit linear 1 12-bit non-linear 2 reserved 3 reserved value meaning ttttrrrraaaacccckkkkppppiiiittttcccchhhh:::: 0 normal track mode 1 wide track mode 2 reserved 3 reserved value meaning ccccooooppppyyyy:::: 0 copy permitted 1 reserved 2 copy prohibited 3 reserved These bits are always present and must be recorded when making your own recordings. The ppppaaaacccckkkk field is optional. It should be filled with zero when not being used. The bits of the ppppaaaacccckkkk field are assembled with the bits of the pack fields from 31 other frames to build one 8-byte subcode pack. These packs are duplicated in the sub data area from where they are much easier to recover. All seven packs can be found in the ppppaaaacccckkkkssss array in DDDDTTTTFFFFRRRRAAAAMMMMEEEE.... SSSSuuuubbbb IIIIDDDD BBBBiiiittttssss The ccccttttrrrrlllliiiidddd field is a bit field with the following meanings: bbbbiiiitttt nnnnaaaammmmeeee mmmmeeeeaaaannnniiiinnnngggg 0 TOC ID set if this program is stored in the table of contents 1 Shortening ID set for 33 +_ 3 frames at the start of shortening play 2 Start ID set for 300 +_ 30 frames at the start of a track 3 Priority ID set when the program number is recorded and is well defined PPPPaaaaggggeeee 3333 DDDDAAAATTTTFFFFRRRRAAAAMMMMEEEE((((4444)))) DDDDAAAATTTTFFFFRRRRAAAAMMMMEEEE((((4444)))) The ddddaaaattttaaaaiiiidddd field is zero for audio use. All other values are reserved. ppppnnnnoooo1111,,,, ppppnnnnoooo2222 and ppppnnnnoooo3333 are 3 BCD digits indicating the current program number. ppppnnnnoooo1111 is the most significant digit. Program numbering starts with the value 001 and has to increase by increments of one. The maximum program number is 799 so ppppnnnnoooo can have values from 0 - 7, and ppppnnnnoooo2222 and ppppnnnnoooo3333 can have values from 0 - 9. The program number can also be one of three special values 0AA means the program number is not currently valid. 0BB means we are in the lead-in area. 0EE means we are in the lead-out area. The program number is only required to be valid when ssssttttaaaarrrrttttiiiidddd is 1, i.e. for 300 +_ 30 frames. so it is likely to disappear and be replaced by 0AA shortly after a track starts. nnnnuuuummmmppppaaaacccckkkkssss is the number of subcode packs actually used in this frame. It usually indicates that all seven packs are recorded even when they are all zero. iiiippppffff contains the interpolation flags, one for each channel as follows: BBBBiiiitttt CCCChhhhaaaannnnnnnneeeellll 0x40 Left IPF 0x20 Right IPF The interpolation flags indicate when uncorrectable errors have been detected during playback leading the DAT drive to interpolate the missing data. It is usually advisable not to play the audio data from a frame with these flags set. Most of SSSSuuuubbbb IIIIDDDD is optional. Only ddddaaaattttaaaaiiiidddd is required and must be zero. If the bits of ccccttttrrrrlllliiiidddd are zero, the bits of the rest of SSSSuuuubbbb IIIIDDDD may also be set to zero and will be ignored. SSSSuuuubbbbccccooooddddeeee PPPPaaaacccckkkkssss Nine different pack items are currently defined and seven are reserved. The nine items are: PPPPaaaacccckkkk IIIIDDDD CCCCoooonnnntttteeeennnntttt 0000 no information 0001 Program Time 0010 Absolute Time 0011 Running Time/Pro R-Time 0100 Table of Contents 0101 Date 0110 Catalog Number 0111 International Standard Recording Code 1000 Pro Binary PPPPrrrrooooggggrrrraaaammmm TTTTiiiimmmmeeee Program Time indicates the time from the beginning of the program. It is stored in a _d_t_t_i_m_e_p_a_c_k structure defined in _d_a_t_a_u_d_i_o._h as follows: PPPPaaaaggggeeee 4444 DDDDAAAATTTTFFFFRRRRAAAAMMMMEEEE((((4444)))) DDDDAAAATTTTFFFFRRRRAAAAMMMMEEEE((((4444)))) /* * The timecode structure looks like this: * * struct dttimecode { * unchar hhi:4, hlo:4; * unchar mhi:4, mlo:4; * unchar shi:4, slo:4; * unchar fhi:4, flo:4; * }; * * This structure is identical to mtaudtimecode in sys/mtio.h so */ #define dttimecode mtaudtimecode /* pack for ptime, atime, rtime and pro-rtime */ struct dttimepack { unchar id:4, flag:1, pno1:3, pno2:4, pno3:4; struct dtpackedbcd {unchar dhi:4, dlo:4;} index; struct dttimecode tc; unchar parity; }; The program number is stored in ppppnnnnoooo1111,,,, ppppnnnnoooo2222,,,, and ppppnnnnoooo3333 as 3 BCD digits exactly like the SSSSuuuubbbb IIIIDDDD field. That information is duplicated here. iiiinnnnddddeeeexxxx is the index number of the current subdivision within the program. The index number is expressed as 2 BCD digits. AA indicates that the index number is invalid. A program may be preceded by an index number of 00 with the same program number. This represents the _m_u_s_i_c _i_n_t_e_r_v_a_l or pause between tracks. Valid index numbers are 01 to 99. Within a program, the first value of the index number is 01 and the value of the index number has to increase by one. The program time is represented by 2 BCD digits each for hours, minutes, seconds and frames. Hours range from 00 to 99, and minutes and seconds from 00 to 59. Over a three second period, frames ranges from 00 to 32, 00 to 32, and 00 to 33. In other words if (seconds modulo 3) is 0 or 1, frames ranges from 00 to 32. If (seconds modulo 3) is 2, frames ranges from 00 to 33. AA indicates the the program time is invalid. The program time is set to zero at the start position of a program and increases within the program. The start position of a program is the first position where the program number is renewed (changed) and the index number is not 00. AAAAbbbbssssoooolllluuuutttteeee TTTTiiiimmmmeeee Absolute time is stored in a ssssttttrrrruuuucccctttt ddddttttttttiiiimmmmeeeeppppaaaacccckkkk identical to program time's. Absolute time is set to 00 at the start of the first program on the tape and increases throughout the tape except on the lead-in area (program number 0BB). The time decreases on the lead-in area and is set to zero at the end point of the lead-in area. PPPPaaaaggggeeee 5555 DDDDAAAATTTTFFFFRRRRAAAAMMMMEEEE((((4444)))) DDDDAAAATTTTFFFFRRRRAAAAMMMMEEEE((((4444)))) When the first program cannot begin after the time is set to zero, the time should be zero continuously until the first program begins. The program number of this area should be 0BB and this area should be less than 33 frames. RRRRuuuunnnnnnnniiiinnnngggg TTTTiiiimmmmeeee Running time is stored in a pack with ID 3, and the ffffllllaaaagggg bit zero. The pack is a time pack identical to program and absolute times'. The running time is a continuously increasing time code beginning from some value at the start point of each recording. The time increases within one recording. PPPPrrrroooo RRRR TTTTiiiimmmmeeee Pro R time is a variation on the running time pack for professional use. Pro R time is indicated when the ffffllllaaaagggg bit is one. Pro R time is stored in a ddddttttpppprrrroooottttiiiimmmmeeeeppppaaaacccckkkk defined in _d_a_t_a_u_d_i_o._h as follows: /* pack for pro-rtime */ struct dtprotimepack { unchar id:4, flag:1, fill:1, sid:2; unchar freq:2, xrate:3, msb:3; unchar lsb; struct dttimecode tc; unchar parity; }; Pro R time stores a running time in the ttttcccc field just like running time. The other fields give addition information about the stored time value. The ssssiiiidddd field indicates the type of time code recorded as follows: vvvvaaaalllluuuueeee mmmmeeeeaaaannnniiiinnnngggg 00 IEC (SMPTE) timecode (IEC 461) 01 local sample address code of Pro DIO time code. 10 time-of-day code of Pro DIO time code (IEC 958) 11 reserved The ffffrrrreeeeqqqq field indicates the sampling frequency used for the time conversion to Pro R time as follows: vvvvaaaalllluuuueeee mmmmeeeeaaaannnniiiinnnngggg 00 48kHz 01 44.1kHz 10 32kHz 11 reserved When the ssssiiiidddd field indicates IEC (SMPTE) time code, the xxxxrrrraaaatttteeee field indicates the transmission rate of the time code as follows: PPPPaaaaggggeeee 6666 DDDDAAAATTTTFFFFRRRRAAAAMMMMEEEE((((4444)))) DDDDAAAATTTTFFFFRRRRAAAAMMMMEEEE((((4444)))) vvvvaaaalllluuuueeee mmmmeeeeaaaannnniiiinnnngggg 000 30Hz 001 29.97Hz, non-drop frame 010 29.97Hz, drop frame 011 25Hz 100 24Hz 101 reserved 110 reserved 111 reserved For any other value of ssssiiiidddd,,,, this field must have the value 000. The mmmmssssbbbb,,,, and llllssssbbbb fields provide 11 bits of binary data. When ssssiiiidddd indicates IEC (SMPTE) time code these bits record a _T_i_m_e _c_o_d_e _M_a_r_k_e_r (_T_C _M_a_r_k_e_r). TC Marker is the time difference between the IEC time code frame and the DAT frame. When ssssiiiidddd indicates one of the Pro DIO time codes, the binary data records the 32-bit binary code corresponding to the first sample of a DAT frame converted into hour, minute, seconds, frame and sample (called the sample number). The range of value indicated by these 11 bits is different for each value of ffffrrrreeeeqqqq as shown in the following table: ffffrrrreeeeqqqquuuueeeennnnccccyyyy rrrraaaannnnggggeeee 48kHz 0 - 1439 44.1kHz 0 - 1322 32kHz 0 - 959. TTTTaaaabbbblllleeee ooooffff CCCCoooonnnntttteeeennnnttttssss The TOC pack contains one entry from the table of contents. The TOC is stored in a _s_t_r_u_c_t _d_t_t_o_c_p_a_c_k defined in _d_a_t_a_u_d_i_o._h as follows: /* pack for table of contents */ struct dttocpack { unchar id:4, flag:1, pno1:3, pno2:4, pno3:4; struct dtpackedbcd point; struct dttimecode atime; unchar parity; }; The table of contents may be recorded repeatedly over the entire length of the tape or only at the beginning of the tape. In the first case it is called _r_e_p_e_a_t_e_d _T_O_C (_R-_T_O_C). In the latter case it is called _u_s_e_r'_s _T_O_C (_U-_T_O_C). The standard table of contents entry has a program number in ppppnnnnoooo1111,,,, ppppnnnnoooo2222 and ppppnnnnoooo3333,,,, and an index number in ppppooooiiiinnnntttt.... The starting position of that program, index pair is given in aaaattttiiiimmmmeeee.... Several special values of ppppnnnnoooo and iiiinnnnddddeeeexxxx with specific meanings are also used. The following table shows PPPPaaaaggggeeee 7777 DDDDAAAATTTTFFFFRRRRAAAAMMMMEEEE((((4444)))) DDDDAAAATTTTFFFFRRRRAAAAMMMMEEEE((((4444)))) these values. PPPPooooiiiinnnntttt PPPPrrrrooooggggrrrraaaammmm NNNNuuuummmmbbbbeeeerrrr AAAAttttiiiimmmmeeee AA 0BB all "0" BB PNO of TOC area all "0" B0 No. of TOC entries all "0" A0 No. of 1st program start of 1st program A1 No. of last program start of last program C0 No. of a skip area start of skip area C1 No. of a skip area end of skip area CC 0BB all "0" EE PNO of TOC area all "0" Point BB is the beginning of the table of contents. Point CC is a continuation of the table of contents. Point EE is the end of the table of contents. A location in absolute time is found by scanning the tape at 150X play speed. Since it is possible to do exactly the same kind of search for a program number, the table of contents is not terribly useful. DDDDaaaatttteeee The date pack is a time stamp giving the time and date of recording. It is stored in a ssssttttrrrruuuucccctttt ddddttttddddaaaatttteeeeppppaaaacccckkkk which is defined in _d_a_t_a_u_d_i_o._h as follows: /* pack for date */ struct dtdatepack { unchar id:4, dayow:4; struct dtpackedbcd year; struct dtpackedbcd month; struct dtpackedbcd day; struct dtpackedbcd hour; struct dtpackedbcd min; struct dtpackedbcd sec; unchar parity; }; CCCCaaaattttaaaalllloooogggg NNNNuuuummmmbbbbeeeerrrr The catalog number pack gives the catalog number expressed in 13 BCD digits according to the UPS/EAN-Code. It is stored in a ssssttttrrrruuuucccctttt ddddttttccccaaaattttaaaallllooooggggppppaaaacccckkkk defined in _d_a_t_a_u_d_i_o._h as follows: /* pack for catalog number */ struct dtcatalogpack { unchar id:4, n1:4; struct dtpackedbcd nrest[6]; unchar parity; }; PPPPaaaaggggeeee 8888 DDDDAAAATTTTFFFFRRRRAAAAMMMMEEEE((((4444)))) DDDDAAAATTTTFFFFRRRRAAAAMMMMEEEE((((4444)))) The catalog number does not change on a tape. When this item is present it occupies at least one of 100 successive frames. IIIInnnntttteeeerrrrnnnnaaaattttiiiioooonnnnaaaallll SSSSttttaaaannnnddddaaaarrrrdddd RRRReeeeccccoooorrrrddddiiiinnnngggg CCCCooooddddeeee The ISRC gives a unique identification code to a recording. It is stored in a _s_t_r_u_c_t _d_t_i_d_e_n_t_p_a_c_k which is defined in _d_a_t_a_u_d_i_o._h as follows: /* pack for ISRC */ struct dtidentpack { unchar id:4, point:2, fill:2; union { struct { unchar country[2]; unchar owner[3]; unchar fill; } point0; struct { struct dtpackedbcd year; struct dtpackedbcd serial[3]; /* serial is 1st 5 digits */ unchar fill[2]; } point1; } data; unchar parity; }; When ppppooooiiiinnnntttt is zero the pack contains the country and owner codes. When ppppooooiiiinnnntttt is one the pack contains the year and serial number. Country and owner are encoded in a six-bit code representing digits and upper case letters. [See _c_d_f_r_a_m_e(_4) for the code.] Year and serial number are BCD digits. The ISRC can only change immediately after the program number changes. When this item is present it occupies at least one of 100 successive frames. PPPPrrrroooo BBBBiiiinnnnaaaarrrryyyy The Pro Binary pack contains either the binary group data of IEC (SMPTE) time code or the status data of Pro DIO time code. It is stored in a ssssttttrrrruuuucccctttt ddddttttpppprrrroooobbbbiiiinnnnaaaarrrryyyyppppaaaacccckkkk which is defined in _d_a_t_a_u_d_i_o._h as follows: /* pack for pro-binary */ struct dtprobinarypack { unchar id:4, fill:2, sid:2; union { struct bgd { unchar fill; unchar tcbits; struct dtpackedbcd bg[4]; } bgd; /* binary group data of IEC time code */ struct csid { PPPPaaaaggggeeee 9999 DDDDAAAATTTTFFFFRRRRAAAAMMMMEEEE((((4444)))) DDDDAAAATTTTFFFFRRRRAAAAMMMMEEEE((((4444)))) unchar csbytes[6]; } csid; /* channel status id of Pro DIO time code */ struct cod { unchar fill[2]; unchar cod[4]; } cod; /* alphanumeric origin data of Pro DIO */ struct cdd { unchar fill[1]; unchar flags; unchar cdd[4]; } cdd; /* alphanumeric destination data of Pro DIO */ } data; unchar parity; }; ssssiiiidddd is a subpack identification identifying what is in this pack as follows: vvvvaaaalllluuuueeee ccccoooonnnntttteeeennnntttt 00 binary group data of IEC (SMPTE) time code 01 channel status ID of Pro DIO time code 10 alphanumeric origin data of Pro DIO 11 alphanumeric destination data of Pro DIO The IEC (SMPTE) binary group data consists of binary group and time code bits. The binary groups are stored as BCD digits in bbbbgggg.... The eighth binary group is stored in bbbbgggg[[[[0000]]]]....ddddhhhhiiii.... The seventh binary group is stored in bbbbgggg[[[[0000]]]]....ddddlllloooo.... The groups continue in descending order through the array with the second group in bbbbgggg[[[[3333]]]]....ddddhhhhiiii and the first group in bbbbgggg[[[[3333]]]]....ddddlllloooo.... The time code bits are used as follows: bbbbiiiitttt IIIIEEEECCCC bbbbiiiitttt 555522225555////66660000 666622225555////55550000 0 10 drop frame unassigned 1 11 color frame color lock 2 27 phase correction binary group flag 3 43 binary group flag binary group flag 4 58 unassigned unassigned 5 59 binary group flag phase correction 6 not used 7 not used When the IEC (SMPTE) time code is recorded for a given frame, the binary group data must also be recorded. The channel status ID consists of bytes 0 to 5 of the channel status data of the IEC serial digital interface stored in bytes 0 to 5 of ddddaaaattttaaaa....ccccddddiiiidddd....ccccssssbbbbyyyytttteeeessss.... PPPPaaaaggggeeee 11110000 DDDDAAAATTTTFFFFRRRRAAAAMMMMEEEE((((4444)))) DDDDAAAATTTTFFFFRRRRAAAAMMMMEEEE((((4444)))) The alphanumeric channel origin data consists of bytes 6 to 9 of the channel status data of the IEC serial digital interface stored in bytes 0 to 3 of ddddaaaattttaaaa....ccccoooodddd....ccccoooodddd.... The alphanumeric channel destination data consists of byte 22 of the channel status data of the IEC serial digital interface stored in ddddaaaattttaaaa....ccccdddddddd....ffffllllaaaaggggssss and bytes 10 to 13 of the channel status data stored in bytes 0 to 4 of ddddaaaattttaaaa....ccccdddddddd....ccccdddddddd.... PPPPaaaacccckkkk PPPPaaaarrrriiiittttyyyy The last byte of a pack is a parity checksum which is computed as the exclusive-OR of the first seven bytes. During playback, the DAT drive executes a parity check and only returns packs with correct parity. During recording, the correct parity value must be computed and written into the parity field before the pack is written to the tape. SSSSEEEEEEEE AAAALLLLSSSSOOOO _T_h_e _D_i_g_i_t_a_l _A_u_d_i_o _T_a_p_e _R_e_c_o_r_d_e_r _S_y_s_t_e_m published by The DAT Conference. c/o Electronic Industries Association of Japan, Engineering Department. Tokyo Chamber of Commerce & Industry Building 2-2, 3-chome, Marunouchi, Chiyoda-ku, Tokyo 100, Japan _D_A_T _f_o_r _P_r_o_f_e_s_s_i_o_n_a_l _U_s_e. The DAT Conference. c/o Electronic Industries Association of Japan, Engineering Department. Tokyo Chamber of Commerce & Industry Building 2-2, 3-chome, Marunouchi, Chiyoda-ku, Tokyo 100, Japan AAAAUUUUTTTTHHHHOOOORRRR Mark Callow PPPPaaaaggggeeee 11111111